LGTM, though I'm not sure I understand the API:

1. Users request to upload N items
2. Users get N upload URLs
3. Users upload N files
4. Users say "Hey, I uploaded " - One weakness here is that clients don't need to report the same number N of files here
5. Users get back some ID? And the task starts running?

A more "bulletproof" API would be something like:

1. Create a portfolio (or portfolio group, or process group whatever primitive files get attached to), get an ID back
2. Request to upload files to that portfolio ID
3. Can do step 2 as many times as is useful, can be batch or not batch, doesn't matter
4. Mark files completed after they're uploaded. We could do this behind the scenes (as noted elsewhere, using blob storage events), but we could also just roll this validation step into step 5 below.
5. Request to start the processing

From the web client's perspective, this whole process could be kicked off in one go once they select their files, it just makes the API slightly harder to misuse, intentionally or accidentally.

OK FWIW, I think this is mostly doing what you think it is, just with a few translations.

• an Incomplete Upload is a file that has been uploaded, but hasn't parsed successfully, either because it failed parsing, or because it is currently processing, or hasn't yet been processed. This staging ground type of approach allows us to have every portfolio in the system correspond to a unit that is fit for any type of processing. The requirements specify things like deleting incomplete uploads by default, and building in that kind of logic over portfolios would have been riskier, etc. When an incomplete upload successfully parses into (one or more) portfolios, we delete the incomplete upload.
• The "Marking as completed" is just the request to start processing - it's just Completes Initial DB Layer #5. There is no Initial Audit Log DB Layer + Tests #4.
• The reason I think it is stronger to request the set of incomplete uploads to process is because if the incomplete upload fails (i.e. file too big and rejected by cloud storage, ex), the client can be smarter about how it handles partial success cases on the frontend, with no requirement for storage on the backend (i.e. we would have to record more concretely the ties between which blobs were uploaded and which were associated with a non-started task, ex, if we didn't specify which things to run when we say "start the run".

Does that make sense?